REMARKS 

The Office Action of November 22, 2005, has been carefully considered. 
Claims 1-23 are pending in the application. 

Claims 1-23 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over U.S. Patent No. 6,314,460 to Knight et al. (hereinafter referred to as the 
Knight reference) in view of US Patent Application No. 2005/0060693 Al to 
Robison et al. (hereinafter referred to as the Robison reference). 

The Applicant submits the following amendments and remarks to traverse 
the above rejections. The Applicant respectfully requests reconsideration and 
allowance of the subject application. This Amendment is believed to be fully 
responsive to all issues raised in the Office Action dated November 22, 2005. 

Claim Rejections Under 35 USC §103(a) 

Claims 1-23 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over the Knight reference in view of the Robison reference. For the 
reasons that follow, the Applicant respectfully disagrees that the subject matter of 
the above claims is obvious given the above cited references. 

Rejection of Independent Claim 1 and its Dependent Claims 2-13 

The Examiner contends that the Knight reference teaches each of the 
elements recited in Claim 1, except that it does not teach "receiving a command 
string" or "separating the command string into one or more string components". 
The Examiner contends that the Robison reference teaches "receiving a command 
string" and "separating the command string into one or more string components". 
Then, the Examiner contends that it would have been obvious to a person having 



ordinary skill in the art at the time the invention was made to have modified the 
Knight reference by the teaching of the Robison reference because do so would 
enable the system to be distributed among remote resources, wherein 
command (strings) are generated by various entities of the system, broken 
down (separated) into various components, and are parsed (transmitted and 
received) by the resolving component" (emphasis added). In addition, the 
Examiner contends that the Robison reference teaches that separating the 
parameter parsing logic from the actual action handler logic leads to better 
separation of concerns and OO-designs. 

In order to best describe why the Applicant disagrees with the Examiner's 
contention, the Applicant again briefly describes an overview of the invention and 
then describes certain aspects in further detail. The Applicant then contrasts the 
claimed invention with the Knight and the Robison references that were cited by 
the Examiner in rejecting Claims 1-13. 

In overview, the present invention is directed at an extended type manager 
that is configured to access precisely parse-able input and to correlate the precisely 
parse-able input with a requested data type. Page 19, lines 3-7. The extended type 
manager may perform this function in response to a request from a parser, a script 
engine, or a pipeline processor. Page 60, lines 12-14. When a pipeline processor 
requests this functionality, the extended type manager resolves partially 
unresolved objects that are piped through the pipeline of the operating 
environment from one object-based command to the next object-based command. 
In addition, strings specified via the object-based command pipeline, may affect 
the processing of incoming objects. For example, property paths specify 
additional processing that is performed on a direct property of an incoming object 



that was originally generated by a prior command. Page 61 line 20 to Page 62, 
line 1 . The extended type manager also allows new data types to be incorporated 
into the operating system by various external sources. Page 20, lines 16-19. Each 
external source may register their unique structure within a type metadata and 
provide code. When the object is queried, the extended type manager reviews the 
type metadata to determine whether the object has been registered. If the object is 
not registered within the type metadata, reflection is performed. Otherwise, 
extended reflection is performed. Page 20, line 23 to Page 21, line 2. Thus, 
depending on the input type, the type metadata describes how the extended type 
manager should query various types of precisely parse-able input to obtain the 
desired properties for creating an object. Page 21, lines 6-9. In addition to 
providing extended types, the extended type manager provides additional query 
mechanisms, such as a property path mechanism, a key mechanism, a compare 
mechanism, a conversion mechanism, a globber mechanism, a relationship 
mechanism, and a property set mechanism. Page 21, lines 13-16. 

In contrast, the Knight reference is directed at an analyzer for a storage 
network attached to a host computer system through multiple controllers that 
receives information from each controller concerning a shared storage network 
bus, and resolves incomplete information received from one controller using 
information received by another controller, as described in the Abstract. The 
"storage network as used herein is an interconnected group of storage devices 
and controllers", as described in Column 5, lines 40-41. With this configuration, 
"it is possible for a host to communicate with any storage device in a storage 
network to which the host is connected, without crossing another host's 
backplane bus." While the Knight reference acknowledges that the network 



configurations that are shown are merely illustrative, it states that the "number of 
host systems, I/O controllers, buses, and storage devices may vary considerably". 
Thus, the shared network may be various configurations of host systems, I/O 
controllers, busses, and storage devices. 

Again, the Applicant disagrees with the Examiner's correlation of "the 
shared storage network" with the "interactive operating environment" recited in 
Claim 1. To further clarify, the Applicant has amended Claim 1 to recite 
"receiving a set of objects output from a prior command via an object-based 
command pipeline" and "processing the set of objects using an operating 
environment mechanism to resolve each object into a data type". In other words, 
objects output from a prior command are received and are processed using an 
operating environment mechanism. Claim 1 1 further clarifies that the set of 
objects is received as input to a subsequent command in the object-based 
command pipeline after processing the set of objects using the operating 
environment mechanism. Thus, the claimed invention is not directed at parsing 
the parameters entered on a command line into objects. 

Upon review of the Robison reference, the Applicant contends that the 
Robison reference merely discloses the parsing of parameters of a command string 
into objects. For example, paragraph [0018] states the following: 

[A]n embodiment of the present invention provides a command-line 
(command string) processing system for an 00 environment. A 
command processor receives a command-string that is parsed into 
character string tokens. A parameter-handler (a type of parser) then 
attempts to match each successive token against command syntax 
descriptions that are loaded from syntax files. If the first token is 
matched against the first item of a command, whether that item is 
defined to be a command keyword or a parameter, then the 
parameter-handler tries to match the next token against the next item 



in the command. This iterative matching process continues until no 
more matching can be performed. If all specified tokens have been 
matched successfully against the command syntax, then it is thus 
determined that the syntax is indeed that of the specified command. 
But if no match is found for one of the tokens, then the command 
processor continues its attempts to match the command-string with 
other syntax descriptions. If the entered command-string does not 
match any syntax description, then an error is indicated and a help 
message, e.g., proper usage of the attempted command or the 
command that most closely matched an invalid command, is 
outputted to the user or external calling module. 



The Robison reference further explains that "the specified token should 
exactly match the keyword expected by the command processor at that position 
and/or context within the command string" in paragraph [0019]. In paragraph 
[0021], the Robison describes the goal of their command string parsing as follows: 

Such a command-line processing system can successfully process 
new command-strings when syntax descriptions for such new 
commands are entered in the syntax descriptions for such new 
commands are entered in the syntax files. New commands are those 
that were previously unsupported by the command-line processing 
system. The parameter-handling modules can be leveraged and 
reused by syntax descriptions. This can promote object-oriented 
design goals and substantially separate command-string parsing and 
processing concerns from the actual code for the command 
execution. The command execution code receives a set of data 
objects on which it can operate rather than a set of tokens that it 
must itself validate and convert to data objects. 



The Applicant contends that neither the Knight reference nor the Robison 
reference nor any permissible combination of both, teach "receiving a set of 
objects output from a prior command via an object-based command pipeline" 
and "processing the set of objects using an operating environment mechanism 



to resolve each object in the set into a data type" (emphasis added) as recited in 
Claim 1. For example, the Robison reference discloses command string parsing 
that separates parameter parsing logic from the actual action handler logic. This 
command string parsing disclosed in the Robison reference does not teach or 
suggest the limitations recited in Claim 1. For example, there is no mention of 
outputting a set of objects by a prior command. Rather, the objects discussed in 
Robison are objects created from the parameters entered on the command line. In 
addition, there is no mention of a "pipeline", let alone an object-based command 
"pipeline" as recited in Claim 1 . 

In summary, the Examiner has not cited any reference that teaches or 
suggests the claimed invention. In fact, even if all of the cited references could be 
combined, their combined teachings could not possibly suggest the present 
invention. In addition, there is no suggestion or motivation to combine these 
references. Thus, for any of the reasons above, the Applicant contends that the 
Knight reference, whether considered alone or with any permissible combination 
of prior art of record, including the Robison reference, does not teach or suggest 
each limitation recited in independent Claim 1. Therefore, the Applicant 
respectfully submits that the §103 rejection of independent Claim 1 is improper, 
and respectfully requests reconsideration and withdrawal of this rejection. 

Furthermore, the dependent Claims 2-13 of Claim 1 include other limitations 
that are not taught or suggested by the prior art of record. For example, Claims 5-8 
recite "receiving a string via the object-based command pipeline". In contrast with 
the teachings in the Robison reference, this string is not parsed into objects, but 
rather the string affects the processing of the set of objects output from a prior 
command via the object-based command pipeline. Claim 5 recites "the string 



includes a wildcard" and "processing by the mechanism comprises producing a 
subset of the set of object". Claim 6 recites "the string includes a property set" 
and "processing by the mechanism comprises identifying a plurality of properties 
associated with the properly set and processing the set of objects based on the 
plurality of properties." Claim 7 recites "the string includes a relation" and 
"processing by the mechanism comprises finding items that the set of objects 
consume based on the relation." Claim 8 recites "the string comprises a property 
path, the property path comprises a series of components that provide navigation 
to a desired property of each object in the set". Thus, the string is not parsed into 
an object as disclosed by the Robison reference. Rather, the string affects the 
processing of the set of objects output from a prior command. Claim 1 1 further 
recites that the "set of objects is received as input to a subsequent command in the 
object-based command pipeline after processing the set of objects using the 
operating environment mechanism". The Robison reference does not disclose, a 
pipeline, an object-based command pipeline, a set of object received as input to a 
subsequent command, and processing the set of object using the operating 
environment mechanism. 

Therefore, for at least the above reasons, Applicant respectfully submits that 
the §103 rejections of dependent Claims 2-13 is improper, and respectfully requests 
reconsideration and withdrawal of this rejection. 



Rejection of Independent Claims 14 and 19 and their Dependent Claims 

The Examiner contends that the Knight reference teaches each of the 
elements recited in independent Claims 14 and 19, except that it does not teach 
"receiving parseable input". The Examiner contends that the Robison reference 
teaches "receiving parseable input". Then, the Examiner again contends that it 
would have been obvious to a person having ordinary skill in the art at the time the 
invention was made to have modified the Knight reference by the teaching of the 
Robison reference because including receiving parseable input, would enable the 
system to be distributed among remote resources, wherein input command 
(strings) are generated by various entities of the system and parsed 
(transmitted and received) by the resolving component", (emphasis added) 

The Examiner now contends that the shared storage networks teaches an 
operating environment as recited in Claims 14 and 19. Without out unnecessarily 
repeating the above arguments for independent Claim 1 , the Applicant states that 
the applicable arguments above also apply to these claims. 

The Applicant has amended independent Claims 14 and 19 to clarify that 
the parseable input is received as "output from a prior command via an object- 
based command pipeline within an operating environment". As discussed above, 
the Robison reference discloses a command string parsing method where strings 
entered on a command line are converted to objects before execution by a 
command. This does not teach or suggest the recited "object-based command 
pipeline" or "receiving parseable input output from a prior command" as recited in 
Claims 14 and 19. 

In summary, the Examiner has not cited any reference that teaches or 
suggests the claimed invention. In fact, even if all of these references could be 



combined, their teachings could not possibly suggest the present invention. In 
addition, there is no suggestion or motivation to combine these references. Thus, 
for at least any of the above reasons, the Applicant contends that the Knight 
reference, whether considered alone or with any permissible combination of prior 
art of record, including the Robison reference, does not teach or suggest each 
limitation recited in independent Claims 14 and 19. Therefore, the Applicant 
respectfully submits that the §103 rejection of independent Claims 14 and 19 is 
improper, and respectfully requests reconsideration and withdrawal of this 
rejection. 

Furthermore, the dependent Claims 15-18 and 20-23 of Claim 14 and 19, 
respectively, include other limitations that are not taught or suggested by the prior art 
of record. Therefore, for at least the above reasons, Applicant respectfully submits 
that the §103 rejections of dependent Claims 15-18 and 20-23 is improper, and 
respectfully requests reconsideration and withdrawal of this rejection. 



Conclusion 

By the foregoing remarks, Applicant believes that pending claims 1-23 are 
allowable and the application is in condition for allowance. Should the Examiner 
have any further issues regarding this application, the Examiner is requested to 
contact the undersigned attorney for the Applicant at the telephone number 
provided below. 

Respectfully Submitted, 

Dated: May 19. 2006 By: /Marcia A. Tunheim Reg. #42189/ 
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